الفئات الأساسية المجردة في بايثون: إتقان تنفيذ البروتوكول مقابل تصميم الواجهة

في عالم تطوير البرمجيات، الهدف الأسمى هو بناء تطبيقات قوية وقابلة للصيانة والتوسع. مع نمو المشاريع من بضعة نصوص برمجية إلى أنظمة معقدة تديرها فرق دولية، تصبح الحاجة إلى هيكل واضح وعقود يمكن التنبؤ بها أمرًا بالغ الأهمية. كيف نضمن أن المكونات المختلفة، التي ربما كتبها مطورون مختلفون عبر مناطق زمنية مختلفة، يمكنها التفاعل بسلاسة وموثوقية؟ تكمن الإجابة في مبدأ التجريد (abstraction).

تمتلك بايثون، بطبيعتها الديناميكية، فلسفة شهيرة للتجريد: "كتابة البط" (duck typing). إذا كان كائن يمشي كبطة ويصدر صوتًا كبطة، فإننا نعامله كبطة. هذه المرونة هي واحدة من أعظم نقاط قوة بايثون، حيث تعزز التطوير السريع والكود النظيف والمقروء. ومع ذلك، في التطبيقات واسعة النطاق، يمكن أن يؤدي الاعتماد فقط على الاتفاقيات الضمنية إلى أخطاء دقيقة وصداع في الصيانة. ماذا يحدث عندما لا تستطيع "البطة" الطيران بشكل غير متوقع؟ هنا تدخل الفئات الأساسية المجردة (Abstract Base Classes - ABCs) في بايثون إلى المسرح، موفرة آلية قوية لإنشاء عقود رسمية دون التضحية بروح بايثون الديناميكية.

ولكن هنا يكمن تمييز حاسم وغالبًا ما يُساء فهمه. الفئات الأساسية المجردة في بايثون ليست أداة ذات مقاس واحد يناسب الجميع. إنها تخدم فلسفتين متميزتين وقويتين في تصميم البرمجيات: إنشاء واجهات (interfaces) رسمية وصريحة تتطلب الوراثة، وتحديد بروتوكولات (protocols) مرنة تتحقق من القدرات. إن فهم الفرق بين هذين النهجين — تصميم الواجهة مقابل تنفيذ البروتوكول — هو مفتاح إطلاق الإمكانات الكاملة للتصميم كائني التوجه في بايثون وكتابة كود مرن وآمن في نفس الوقت. سيستكشف هذا الدليل كلتا الفلسفتين، مقدمًا أمثلة عملية وإرشادات واضحة حول متى يجب استخدام كل نهج في مشاريعك البرمجية العالمية.

ملاحظة حول التنسيق: للالتزام بقيود تنسيق محددة، يتم عرض أمثلة الكود في هذه المقالة داخل وسوم نصية قياسية باستخدام الأنماط الغامقة والمائلة. نوصي بنسخها إلى محرر الكود الخاص بك للحصول على أفضل قراءة.

الأساس: ما هي الفئات الأساسية المجردة بالضبط؟

قبل الخوض في فلسفتي التصميم، دعنا نؤسس قاعدة صلبة. ما هي الفئة الأساسية المجردة؟ في جوهرها، الفئة الأساسية المجردة هي مخطط لفئات أخرى. تحدد مجموعة من التوابع والخصائص التي يجب على أي فئة فرعية متوافقة تنفيذها. إنها طريقة للقول، "أي فئة تدعي أنها جزء من هذه العائلة يجب أن تمتلك هذه القدرات المحددة."

توفر وحدة `abc` المدمجة في بايثون الأدوات اللازمة لإنشاء الفئات الأساسية المجردة. المكونان الأساسيان هما:

• `ABC`: فئة مساعدة تُستخدم كـ metaclass لإنشاء فئة أساسية مجردة. في بايثون الحديثة (3.4+)، يمكنك ببساطة الوراثة من `abc.ABC`.
• `@abstractmethod`: مُزخرف (decorator) يُستخدم لوضع علامة على التوابع بأنها مجردة. يجب على أي فئة فرعية من الفئة الأساسية المجردة تنفيذ هذه التوابع.

هناك قاعدتان أساسيتان تحكمان الفئات الأساسية المجردة:

1. لا يمكنك إنشاء مثيل (instance) من فئة أساسية مجردة تحتوي على توابع مجردة غير منفذة. إنها قالب، وليست منتجًا نهائيًا.
2. يجب على أي فئة فرعية ملموسة (concrete subclass) تنفيذ جميع التوابع المجردة الموروثة. إذا فشلت في القيام بذلك، فإنها تصبح أيضًا فئة مجردة، ولا يمكنك إنشاء مثيل منها.

دعنا نرى هذا عمليًا بمثال كلاسيكي: نظام لمعالجة ملفات الوسائط.

مثال: فئة أساسية مجردة بسيطة لـ MediaFile

تخيل أننا نبني تطبيقًا يحتاج إلى التعامل مع أنواع مختلفة من الوسائط. نحن نعلم أن كل ملف وسائط، بغض النظر عن تنسيقه، يجب أن يكون قابلاً للتشغيل وأن يحتوي على بعض البيانات الوصفية. يمكننا تحديد هذا العقد باستخدام فئة أساسية مجردة.

import abc

class MediaFile(abc.ABC):
    def __init__(self, filepath: str):
        self.filepath = filepath
        print(f"Base init for {self.filepath}")
    @abc.abstractmethod
    def play(self) -> None:
        """تشغيل ملف الوسائط."""
        raise NotImplementedError
    @abc.abstractmethod
    def get_metadata(self) -> dict:
        """إرجاع قاموس من البيانات الوصفية للوسائط."""
        raise NotImplementedError

إذا حاولنا إنشاء مثيل من `MediaFile` مباشرة، ستوقفنا بايثون:

# سيؤدي هذا إلى إثارة خطأ TypeError
# media = MediaFile("path/to/somefile.txt")
# TypeError: Can't instantiate abstract class MediaFile with abstract methods get_metadata, play

لاستخدام هذا المخطط، يجب علينا إنشاء فئات فرعية ملموسة توفر تطبيقات لـ `play()` و `get_metadata()`.

class AudioFile(MediaFile):
    def play(self) -> None:
        print(f"Playing audio from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "mp3", "duration_seconds": 180}
class VideoFile(MediaFile):
    def play(self) -> None:
        print(f"Playing video from {self.filepath}...")
    def get_metadata(self) -> dict:
        return {"codec": "h264", "resolution": "1920x1080"}

الآن، يمكننا إنشاء مثيلات من `AudioFile` و `VideoFile` لأنهما يفيان بالعقد المحدد بواسطة `MediaFile`. هذه هي الآلية الأساسية للفئات الأساسية المجردة. لكن القوة الحقيقية تأتي من *كيفية* استخدامنا لهذه الآلية.

الفلسفة الأولى: الفئات الأساسية المجردة كتصميم واجهة رسمية (الكتابة الاسمية)

الطريقة الأولى والأكثر تقليدية لاستخدام الفئات الأساسية المجردة هي لتصميم الواجهات الرسمية. يعتمد هذا النهج على الكتابة الاسمية (nominal typing)، وهو مفهوم مألوف للمطورين القادمين من لغات مثل Java أو C++ أو C#. في نظام اسمي، يتم تحديد توافق النوع من خلال اسمه وتصريحه الصريح. في سياقنا، تُعتبر الفئة `MediaFile` فقط إذا ورثت صراحةً من الفئة الأساسية المجردة `MediaFile`.

فكر في الأمر كشهادة مهنية. لكي تكون مدير مشروع معتمدًا، لا يمكنك فقط التصرف كواحد؛ يجب عليك الدراسة، واجتياز امتحان معين، والحصول على شهادة رسمية تنص صراحة على مؤهلاتك. اسم ونسب شهادتك يهم.

في هذا النموذج، تعمل الفئة الأساسية المجردة كعقد غير قابل للتفاوض. من خلال الوراثة منها، تقدم الفئة وعدًا رسميًا لبقية النظام بأنها ستوفر الوظائف المطلوبة.

مثال: إطار عمل لتصدير البيانات

تخيل أننا نبني إطار عمل يسمح للمستخدمين بتصدير البيانات إلى تنسيقات مختلفة. نريد أن نضمن أن كل إضافة (plugin) للتصدير تلتزم بهيكل صارم. يمكننا تحديد واجهة `DataExporter`.

import abc
from datetime import datetime
class DataExporter(abc.ABC):
    """واجهة رسمية لفئات تصدير البيانات."""
    @abc.abstractmethod
    def export(self, data: list[dict]) -> str:
        """تصدير البيانات وإرجاع رسالة حالة."""
        pass
    def get_timestamp(self) -> str:
        """طريقة مساعدة ملموسة مشتركة بين جميع الفئات الفرعية."""
        return datetime.utcnow().isoformat()
class CSVExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.csv"
        print(f"Exporting {len(data)} rows to {filename}")
        # ... منطق كتابة ملف CSV الفعلي ...
        return f"Successfully exported to {filename}"
class JSONExporter(DataExporter):
    def export(self, data: list[dict]) -> str:
        filename = f"export_{self.get_timestamp()}.json"
        print(f"Exporting {len(data)} records to {filename}")
        # ... منطق كتابة ملف JSON الفعلي ...
        return f"Successfully exported to {filename}"

هنا، `CSVExporter` و `JSONExporter` هما صراحةً وبشكل قابل للتحقق `DataExporter`. يمكن للمنطق الأساسي لتطبيقنا الاعتماد بأمان على هذا العقد:

def run_export_process(exporter: DataExporter, data_to_export: list[dict]):
    print("--- Starting export process ---")
    if not isinstance(exporter, DataExporter):
        raise TypeError("Exporter must be a valid DataExporter implementation.")
    status = exporter.export(data_to_export)
    print(f"Process finished with status: {status}")
# Usage
data = [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]
run_export_process(CSVExporter(), data)
run_export_process(JSONExporter(), data)

لاحظ أن الفئة الأساسية المجردة توفر أيضًا طريقة ملموسة، `get_timestamp()`، والتي تقدم وظائف مشتركة لجميع أبنائها. هذا نمط شائع وقوي في التصميم القائم على الواجهات.

إيجابيات وسلبيات نهج الواجهة الرسمية

الإيجابيات:

• لا لبس فيه وصريح: العقد واضح تمامًا. يمكن للمطور رؤية سطر الوراثة `class CSVExporter(DataExporter):` وفهم دور الفئة وقدراتها على الفور.
• صديق للأدوات: يمكن لبيئات التطوير المتكاملة (IDEs) والمحللات الساكنة التحقق بسهولة من العقد، مما يوفر إكمالًا تلقائيًا ممتازًا والتحقق من الأخطاء.
• وظائف مشتركة: يمكن للفئات الأساسية المجردة توفير توابع ملموسة، تعمل كفئة أساسية حقيقية وتقلل من تكرار الكود.
• الألفة: هذا النمط يمكن التعرف عليه فورًا من قبل المطورين من الغالبية العظمى من اللغات الأخرى كائنية التوجه.

السلبيات:

• الاقتران المحكم: ترتبط الفئة الملموسة الآن مباشرة بالفئة الأساسية المجردة. إذا احتاجت الفئة الأساسية المجردة إلى نقلها أو تغييرها، تتأثر جميع الفئات الفرعية.
• الصلابة: يفرض علاقة هرمية صارمة. ماذا لو كانت فئة يمكن أن تعمل منطقيًا كمصدر ولكنها ترث بالفعل من فئة أساسية مختلفة وضرورية؟ يمكن للوراثة المتعددة في بايثون حل هذا، ولكن يمكن أن تقدم أيضًا تعقيداتها الخاصة (مثل مشكلة المعين - Diamond Problem).
• تغلغلي: لا يمكن استخدامه لتكييف كود من جهة خارجية. إذا كنت تستخدم مكتبة توفر فئة بها تابع `export()`، فلا يمكنك جعلها `DataExporter` دون إنشاء فئة فرعية منها (وهو ما قد لا يكون ممكنًا أو مرغوبًا فيه).

الفلسفة الثانية: الفئات الأساسية المجردة كتنفيذ للبروتوكول (الكتابة الهيكلية)

الفلسفة الثانية، الأكثر "بايثونية"، تتماشى مع كتابة البط. يستخدم هذا النهج الكتابة الهيكلية (structural typing)، حيث يتم تحديد التوافق ليس بالاسم أو النسب، ولكن بالهيكل والسلوك. إذا كان الكائن يمتلك التوابع والسمات اللازمة للقيام بالعمل، فإنه يعتبر النوع الصحيح للعمل، بغض النظر عن التسلسل الهرمي للفئة المعلنة.

فكر في القدرة على السباحة. لكي تُعتبر سباحًا، لا تحتاج إلى شهادة أو أن تكون جزءًا من شجرة عائلة "السباحين". إذا كان بإمكانك دفع نفسك عبر الماء دون أن تغرق، فأنت، هيكليًا، سباح. يمكن للشخص والكلب والبطة أن يكونوا جميعًا سباحين.

يمكن استخدام الفئات الأساسية المجردة لإضفاء الطابع الرسمي على هذا المفهوم. بدلاً من فرض الوراثة، يمكننا تحديد فئة أساسية مجردة تتعرف على الفئات الأخرى كفئات فرعية افتراضية لها إذا كانت تنفذ البروتوكول المطلوب. يتم تحقيق ذلك من خلال طريقة سحرية خاصة: `__subclasshook__`.

عند استدعاء `isinstance(obj, MyABC)` أو `issubclass(SomeClass, MyABC)`، تتحقق بايثون أولاً من الوراثة الصريحة. إذا فشل ذلك، فإنها تتحقق بعد ذلك مما إذا كانت `MyABC` تحتوي على تابع `__subclasshook__`. إذا كان الأمر كذلك، فإن بايثون تستدعيه، سائلةً: "مرحباً، هل تعتبر هذه الفئة فئة فرعية لك؟" هذا يسمح للفئة الأساسية المجردة بتحديد معايير عضويتها بناءً على الهيكل.

مثال: بروتوكول `Serializable`

دعنا نحدد بروتوكولًا للكائنات التي يمكن تسلسلها إلى قاموس. لا نريد إجبار كل كائن قابل للتسلسل في نظامنا على الوراثة من فئة أساسية مشتركة. قد تكون نماذج قاعدة بيانات، أو كائنات نقل بيانات، أو حاويات بسيطة.

import abc
class Serializable(abc.ABC):
    @abc.abstractmethod
    def to_dict(self) -> dict:
        pass
    @classmethod
    def __subclasshook__(cls, C):
        if cls is Serializable:
            # التحقق مما إذا كانت 'to_dict' موجودة في ترتيب تحليل التوابع لـ C
            if any("to_dict" in B.__dict__ for B in C.__mro__):
                return True
        return NotImplemented

الآن، دعنا ننشئ بعض الفئات. بشكل حاسم، لن يرث أي منها من `Serializable`.

class User:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    def to_dict(self) -> dict:
        return {"name": self.name, "email": self.email}
class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
# هذه الفئة لا تتوافق مع البروتوكول
class Configuration:
    def __init__(self, setting: str):
        self.setting = setting

دعنا نتحقق منها مقابل بروتوكولنا:

print(f"Is User serializable? {isinstance(User('Test', 't@t.com'), Serializable)}")
print(f"Is Product serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
print(f"Is Configuration serializable? {isinstance(Configuration('ON'), Serializable)}")
# المخرجات:
# هل المستخدم قابل للتسلسل؟ True
# هل المنتج قابل للتسلسل؟ False <- انتظر، لماذا؟ دعنا نصلح هذا.
# هل الإعدادات قابلة للتسلسل؟ False

آه، خطأ مثير للاهتمام! فئتنا `Product` لا تحتوي على تابع `to_dict`. دعنا نضيفه.

class Product:
    def __init__(self, sku: str, price: float):
        self.sku = sku
        self.price = price
    def to_dict(self) -> dict: # إضافة الطريقة
        return {"sku": self.sku, "price": self.price}
print(f"Is Product now serializable? {isinstance(Product('T-1000', 99.99), Serializable)}")
# المخرجات:
# هل المنتج الآن قابل للتسلسل؟ True

على الرغم من أن `User` و `Product` لا يشتركان في فئة أصل مشتركة (بخلاف `object`)، يمكن لنظامنا أن يعاملهما كليهما على أنهما `Serializable` لأنهما يفيان بالبروتوكول. هذا قوي بشكل لا يصدق لفك الاقتران (decoupling).

إيجابيات وسلبيات نهج البروتوكول

الإيجابيات:

• أقصى قدر من المرونة: يعزز الاقتران الفضفاض للغاية. تهتم المكونات فقط بالسلوك، وليس بنسب التنفيذ.
• القدرة على التكيف: مثالي لتكييف الكود الحالي، خاصة من مكتبات الطرف الثالث، ليتناسب مع واجهات نظامك دون تغيير الكود الأصلي.
• يعزز التركيب (Composition): يشجع على أسلوب تصميم حيث يتم بناء الكائنات من قدرات مستقلة بدلاً من خلال أشجار وراثة عميقة وصارمة.

السلبيات:

• عقد ضمني: العلاقة بين فئة وبروتوكول تنفذه ليست واضحة على الفور من تعريف الفئة. قد يحتاج المطور إلى البحث في قاعدة الكود لفهم سبب معاملة كائن `User` على أنه `Serializable`.
• عبء وقت التشغيل: يمكن أن يكون فحص `isinstance` أبطأ حيث يتعين عليه استدعاء `__subclasshook__` وإجراء فحوصات على توابع الفئة.
• احتمالية التعقيد: يمكن أن يصبح المنطق داخل `__subclasshook__` معقدًا للغاية إذا كان البروتوكول يتضمن توابع متعددة أو وسائط أو أنواع إرجاع.

التوليف الحديث: `typing.Protocol` والتحليل الساكن

مع نمو استخدام بايثون في الأنظمة واسعة النطاق، زادت الرغبة في تحليل ساكن أفضل. نهج `__subclasshook__` قوي ولكنه آلية وقت تشغيل بحتة. ماذا لو تمكنا من الحصول على فوائد الكتابة الهيكلية *قبل* حتى تشغيل الكود؟

أدى هذا إلى إدخال `typing.Protocol` في PEP 544. إنه يوفر طريقة موحدة وأنيقة لتعريف البروتوكولات التي تهدف في المقام الأول إلى مدققات الأنواع الساكنة مثل Mypy أو Pyright أو مفتش PyCharm.

تعمل فئة `Protocol` بشكل مشابه لمثال `__subclasshook__` الخاص بنا ولكن بدون الكود المتكرر. يمكنك ببساطة تحديد التوابع وتوقيعاتها. أي فئة لديها توابع وتوقيعات مطابقة ستعتبر متوافقة هيكليًا بواسطة مدقق النوع الساكن.

مثال: بروتوكول `Quacker`

دعنا نعود إلى مثال كتابة البط الكلاسيكي، ولكن بأدوات حديثة.

from typing import Protocol
class Quacker(Protocol):
    def quack(self, volume: int) -> str:
        """تنتج صوت بطبطة."""
        ... # ملاحظة: ليس من الضروري وجود جسم لطريقة البروتوكول
class Duck:
    def quack(self, volume: int) -> str:
        return f"QUACK! (at volume {volume})"
class Dog:
    def bark(self, volume: int) -> str:
        return f"WOOF! (at volume {volume})"
def make_sound(animal: Quacker):
    print(animal.quack(10))
make_sound(Duck()) # يمر تحليل الكود الثابت
make_sound(Dog()) # يفشل تحليل الكود الثابت!

إذا قمت بتشغيل هذا الكود من خلال مدقق أنواع مثل Mypy، فسوف يضع علامة على السطر `make_sound(Dog())` بخطأ: `Argument 1 to "make_sound" has incompatible type "Dog"; expected "Quacker"`. يفهم مدقق الأنواع أن `Dog` لا يفي ببروتوكول `Quacker` لأنه يفتقر إلى تابع `quack`. هذا يكتشف الخطأ قبل حتى تنفيذ الكود.

بروتوكولات وقت التشغيل مع `@runtime_checkable`

بشكل افتراضي، `typing.Protocol` مخصص للتحليل الساكن فقط. إذا حاولت استخدامه في فحص `isinstance` في وقت التشغيل، فستحصل على خطأ.

# isinstance(Duck(), Quacker) # -> TypeError: Protocol 'Quacker' cannot be instantiated

ومع ذلك، يمكنك سد الفجوة بين التحليل الساكن وسلوك وقت التشغيل باستخدام المزخرف `@runtime_checkable`. هذا يخبر بايثون بشكل أساسي بإنشاء منطق `__subclasshook__` لك تلقائيًا.

from typing import Protocol, runtime_checkable
@runtime_checkable
class Quacker(Protocol):
    def quack(self, volume: int) -> str: ...
class Duck:
    def quack(self, volume: int) -> str: return "..."
print(f"Is Duck an instance of Quacker? {isinstance(Duck(), Quacker)}")
# المخرجات:
# هل البطة هي مثيل من Quacker؟ True

يمنحك هذا أفضل ما في العالمين: تعريفات بروتوكول نظيفة وتصريحية للتحليل الساكن، وخيار التحقق في وقت التشغيل عند الحاجة. ومع ذلك، كن على دراية بأن عمليات التحقق في وقت التشغيل على البروتوكولات أبطأ من استدعاءات `isinstance` القياسية، لذا يجب استخدامها بحكمة.

اتخاذ القرارات العملية: دليل المطور العالمي

إذًا، أي نهج يجب أن تختار؟ تعتمد الإجابة كليًا على حالة الاستخدام الخاصة بك. إليك دليل عملي بناءً على سيناريوهات شائعة في مشاريع البرمجيات الدولية.

السيناريو 1: بناء بنية إضافات لمنتج SaaS عالمي

أنت تصمم نظامًا (على سبيل المثال، منصة تجارة إلكترونية، نظام إدارة محتوى) سيتم توسيعه بواسطة مطورين من الطرف الأول والثالث حول العالم. تحتاج هذه الإضافات إلى التكامل العميق مع تطبيقك الأساسي.

• التوصية: واجهة رسمية (Nominal `abc.ABC`).
• المنطق: الوضوح والاستقرار والصراحة هي الأهم. أنت بحاجة إلى عقد غير قابل للتفاوض يجب على مطوري الإضافات الاشتراك فيه بوعي من خلال الوراثة من `BasePlugin` ABC الخاص بك. هذا يجعل واجهة برمجة التطبيقات الخاصة بك لا لبس فيها. يمكنك أيضًا توفير توابع مساعدة أساسية (على سبيل المثال، للتسجيل، والوصول إلى التكوين، والتدويل) في الفئة الأساسية، وهي فائدة كبيرة لنظامك البيئي للمطورين.

السيناريو 2: معالجة البيانات المالية من واجهات برمجة تطبيقات متعددة وغير مرتبطة

يحتاج تطبيق التكنولوجيا المالية الخاص بك إلى استهلاك بيانات المعاملات من بوابات دفع عالمية مختلفة: Stripe، PayPal، Adyen، وربما مزود إقليمي مثل Mercado Pago في أمريكا اللاتينية. الكائنات التي تعيدها حزم SDK الخاصة بهم خارجة تمامًا عن سيطرتك.

• التوصية: بروتوكول (`typing.Protocol`).
• المنطق: لا يمكنك تعديل الكود المصدري لهذه الحزم SDK التابعة لجهات خارجية لجعلها ترث من فئة `Transaction` الأساسية الخاصة بك. ومع ذلك، فأنت تعلم أن كل كائن من كائنات المعاملات الخاصة بهم لديه توابع مثل `get_id()`، `get_amount()`، و `get_currency()`، حتى لو كانت أسماؤها مختلفة قليلاً. يمكنك استخدام نمط المحول (Adapter pattern) مع `TransactionProtocol` لإنشاء عرض موحد. يسمح لك البروتوكول بتحديد *شكل* البيانات التي تحتاجها، مما يتيح لك كتابة منطق معالجة يعمل مع أي مصدر بيانات، طالما يمكن تكييفه ليناسب البروتوكول.

السيناريو 3: إعادة هيكلة تطبيق قديم ضخم ومترابط

أنت مكلف بتفكيك تطبيق قديم متجانس إلى خدمات مصغرة حديثة. قاعدة الكود الحالية عبارة عن شبكة معقدة من التبعيات، وتحتاج إلى إدخال حدود واضحة دون إعادة كتابة كل شيء مرة واحدة.

• التوصية: مزيج، ولكن مع الاعتماد بشكل كبير على البروتوكولات.
• المنطق: البروتوكولات هي أداة استثنائية لإعادة الهيكلة التدريجية. يمكنك البدء بتحديد الواجهات المثالية بين الخدمات الجديدة باستخدام `typing.Protocol`. بعد ذلك، يمكنك كتابة محولات لأجزاء من التطبيق القديم لتتوافق مع هذه البروتوكولات دون تغيير الكود القديم الأساسي على الفور. يتيح لك هذا فك اقتران المكونات بشكل تدريجي. بمجرد فك اقتران مكون بالكامل وتواصله فقط عبر البروتوكول، يصبح جاهزًا لاستخراجه في خدمته الخاصة. يمكن استخدام الفئات الأساسية المجردة الرسمية لاحقًا لتحديد النماذج الأساسية داخل الخدمات الجديدة والنظيفة.

الخاتمة: نسج التجريد في الكود الخاص بك

تُعد الفئات الأساسية المجردة في بايثون شهادة على التصميم العملي للغة. إنها توفر مجموعة أدوات متطورة للتجريد تحترم كلاً من الانضباط المنظم للبرمجة كائنية التوجه التقليدية والمرونة الديناميكية لكتابة البط.

الرحلة من اتفاق ضمني إلى عقد رسمي هي علامة على نضج قاعدة الكود. من خلال فهم فلسفتي الفئات الأساسية المجردة، يمكنك اتخاذ قرارات معمارية مستنيرة تؤدي إلى تطبيقات أنظف وأكثر قابلية للصيانة وقابلة للتوسع بشكل كبير.

لتلخيص النقاط الرئيسية:

• تصميم الواجهة الرسمية (الكتابة الاسمية): استخدم `abc.ABC` مع الوراثة المباشرة عندما تحتاج إلى عقد صريح لا لبس فيه وقابل للاكتشاف. هذا مثالي لأطر العمل وأنظمة الإضافات والمواقف التي تتحكم فيها في التسلسل الهرمي للفئات. يتعلق الأمر بـ ما هي الفئة حسب التصريح.
• تنفيذ البروتوكول (الكتابة الهيكلية): استخدم `typing.Protocol` عندما تحتاج إلى المرونة وفك الاقتران والقدرة على تكييف الكود الحالي. هذا مثالي للعمل مع المكتبات الخارجية، وإعادة هيكلة الأنظمة القديمة، والتصميم لتعدد الأشكال السلوكي. يتعلق الأمر بـ ما يمكن أن تفعله الفئة حسب هيكلها.

الاختيار بين الواجهة والبروتوكول ليس مجرد تفصيل تقني؛ إنه قرار تصميم أساسي سيشكل كيفية تطور برنامجك. من خلال إتقان كليهما، فإنك تجهز نفسك لكتابة كود بايثون ليس قويًا وفعالًا فحسب، بل أيضًا أنيقًا ومرنًا في مواجهة التغيير.